In relational databases, data is organized into tables. A collection of such tables in a database is referred to as a table space. Database users sometimes inadvertently delete, or drop, a table from a table space. Typically, a database management system (DBMS) does not permit undelete of the drop action: once the table drop is committed, the table's data is permanently deleted and cannot be brought back by way of such a command as an undelete of the drop statement. Instead, the data must be restored from a backup and then the data rolled forward by replaying stored transactions on the data, a potentially slow process.
In certain DBMS environments, such as DB2**, recovering a dropped table is made even more difficult by the fact that a table space restore followed by a roll forward of the table space to a point in time prior to the drop cannot be done. This restriction means that to roll forward to recover a dropped table, the entire database, and not only the effected table space, must be rolled forward. This restriction on the roll forward of the table space is due to the minimum recovery time property. A table space must be rolled forward to at least the minimum recovery time so that it is synchronized with the information in the system catalog tables. The minimum recovery time is updated when data definition language (DDL) statements are executed against a table space, or against tables in a table space.
The minimum recovery time will be later than the time at which the table was dropped. Because of this fact, it is a requirement in typical DBMS environments that the user must recover the entire database. This means that the entire database becomes unavailable to other users while the recovery and rollforward of the database is being carried out. It is typically slower to perform the recovery and restore on the entire database than a recovery and rollforward on the effected table space, only.
The only means in which a dropped table can be currently recovered in many relational databases, such as DB2, is through a database restore followed by a database roll forward to a point in time just prior to the table drop. As indicated above, such an approach will make the database as a whole unavailable to users. It may also be difficult to pinpoint when a table was dropped and therefore data will often be inaccurately retrieved due to uncertainties about when the table in question was dropped. In addition, the structure of the table may no longer be accurately known.
It is therefore desirable to have a DBMS in which tables that have been dropped may be recovered without the need to recover and roll forward the entire database and which permits the point at which the table was dropped to be determined with some accuracy, as well as to determine the structure of the table at the time of the drop.